I don't want to approve this change myself because I've not followed closely enough the discussions to know the policy about adding new commands. In particular, is "simplify" clear enough, or should it be "simplify-tree", or whatever?

But I would have had a use for it as recently as today, when one of my PR (change A) was merged into main: one of my development subtree was based both on this change A and another unmerged one (change B). After rebasing B onto main, I ended up for my dev subtree parents with a merge between a descendant of main (B) and what was now a parent of main (A). A jj simplify here would have saved me the manual rebasing of my subtree on B only.

In this case it was only one subtree with only two parents, and a simple operation, but with a more complex development tree I can see how it would have been even more useful.

In particular, is "simplify" clear enough, or should it be "simplify-tree", or whatever?

I don't have a good suggestion, but I feel "simplify" is too generic. If we use "simplify-", "simplify-parents" is probably better.

Done, changed to simplify-parents for now.

Idk if the file should still be named 'simplify.rs' to leave room for others, but I changed it to simplify_parents.rs also for now

simplify-parents seems rather wordy to be in the top-level namespace, but other than that I think it's fine. I suspect it might be best to go under a utils subcommand or something like we've talked about before, but I'm interested in what other people think.

nit: the commit message still contains simplify instead of simplify-parents

Find and replace, my greatest weakness

simplify-parents seems rather wordy to be in the top-level namespace, but other than that I think it's fine. I suspect it might be best to go under a utils subcommand or something like we've talked about before, but I'm interested in what other people think.

Yeah. If we had a generic graph reshaping command or command namespace, simplify can be moved there. This could also be rebase --simplify-ancestor-merge, but it's inconvenient if the use case is to eliminate redundant edges created by autorebase.

@ilyagr any thoughts?

I think simplify-parents is fine for now, unless we get a better idea.

One alternative I can think of is to have a subcommand, e.g. jj graph simplify-parents or jj graph-util simplify-parents.

Yet another option would be to make jj rebase a namespace with jj rebase source instead of jj rebase -s, and then we could have jj rebase simplify-parents.

Another command that could go into this namespace (or be an option to rebase) is jj reparent-children --from X --to Y (or move-children) that replaces X with Y in the list of any commit's children (without breaking merge commits). I keep meaning to and not quire writing up an FR or PR for it.

I like the idea of jj graph simplify-parents, it would probably make sense to also move jj parallelize into this subgroup? (Also is anyone making jj linearize yet, that would also fit here?)

Operation history is also a "graph", so I think jj graph is still vague.

it would probably make sense to also move jj parallelize into this subgroup?

It might make sense, but I tend to prefer flattened command structure. jj parallelize isn't so ambiguous compared to jj simplify (without -parents/-merge.)

If we add a graph command category, then it seems like even rebase would belong under it, but if we do that, then basically everyone would create an alias for it anyway.

Operation history is also a "graph", so I think jj graph is still vague.

This is a good point. jj commits or jj commitgraph or jj cgraph seem like obvious alternatives, but I'm not sure they are great (jj commit would be better if the current jj commit command did not exist or was renamed). Or we could just accept it and have jj graph, jj evo graph (or evo-graph or evograph), and jj op graph, slimilarly to jj log/evo-log/op log.

If we add a graph command category, then it seems like even rebase would belong under it, but if we do that, then basically everyone would create an alias for it anyway.

I wouldn't mind jj rebase being an alias for jj graph rebase. It'd be unclear whether jj duplicate should also be in jj graph. If it was called jj commit, it'd be easier to make many commands (new, squash, log, etc.) have canonical names like jj commit new.

On the other hand, if we just want the uncommon commands to be in a subcommand, it could be jj graph-utils simplify-parents or jj util graph simplify-parents.

Another idea, based on Yuya's comment is jj simplify parents. But, in any case, we could start with jj simplify-parents.

By the way, I agree with this approach of dealing with redundant ancestry overall. It seems more predictable to me than trying to do simplification automatically in some situations. (Well, I suppose, if we have some great ideas about auto-simplification, this PR doesn't prevent us trying to do that too, but I'm not optimistic about that at the moment).

Would it be a good idea to set a default revset + configuration for jj simplify-parents (like jj fix)?